<html>
<head><meta charset="utf-8"><title>rustc cranelift backend for const eval · t-compiler/const-eval · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/index.html">t-compiler/const-eval</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rustc.20cranelift.20backend.20for.20const.20eval.html">rustc cranelift backend for const eval</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="209218445"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rustc%20cranelift%20backend%20for%20const%20eval/near/209218445" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Benedikt Mandelkow <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rustc.20cranelift.20backend.20for.20const.20eval.html#209218445">(Sep 06 2020 at 10:05)</a>:</h4>
<p>I briefly talked to oli-obk about this idea and he kindly tried to explain to me why it would not work  but I'm still not sufficiently convinced which is why I wanted to bring this up here again.<br>
The idea is that the wip rustc cranelift backend could be used to jit execute const eval code and thus make it faster.<br>
The downside/ concern as I understood is that it may not be able to check all invariants like miri and also that it might do incompatible things like stuff involving addresses.</p>
<p>My argument is basically: </p>
<ol>
<li>Everything involving a memory address can never leak into the executable because const fn must not contain operations which leak these details so cranelift is free to do whatever it wants.</li>
<li>There was talk in some meeting about whether or not it would be feasible to have miri check every kind of violation during const eval and it was said that thats way too slow and unfeasible. So my argument here is that cranelift would possibly do less checking than miri but its a tradeoff anyway so it would not rule out a faster const eval "backend" directly.</li>
</ol>
<p>This jit backend would probably be optional if it ever happened.</p>
<p>Would like to hear thoughts on why this will not work :D</p>



<a name="209218698"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rustc%20cranelift%20backend%20for%20const%20eval/near/209218698" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rustc.20cranelift.20backend.20for.20const.20eval.html#209218698">(Sep 06 2020 at 10:13)</a>:</h4>
<p>Miri knows which parts of a memory allocation are bytes and which are relocations. cg_clif doesn't. It just sees integers. It doesn't know if they are bytes or relocations. For example</p>
<div class="codehilite"><pre><span></span><code><span class="cp">#![feature(const_fn)]</span><span class="w"></span>

<span class="k">const</span><span class="w"> </span><span class="k">fn</span> <span class="nf">a</span><span class="p">()</span><span class="w"> </span>-&gt; <span class="o">*</span><span class="k">const</span><span class="w"> </span><span class="kt">u8</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="k">unsafe</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="n">std</span>::<span class="n">mem</span>::<span class="n">transmute</span>::<span class="o">&lt;&amp;</span><span class="kt">u8</span><span class="p">,</span><span class="w"> </span><span class="o">*</span><span class="k">const</span><span class="w"> </span><span class="kt">u8</span><span class="o">&gt;</span><span class="p">(</span><span class="o">&amp;</span><span class="mi">0</span><span class="p">)</span><span class="w"> </span><span class="p">}</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>

<span class="k">const</span><span class="w"> </span><span class="k">fn</span> <span class="nf">b</span><span class="p">()</span><span class="w"> </span>-&gt; <span class="o">*</span><span class="k">const</span><span class="w"> </span><span class="kt">u8</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="k">unsafe</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="n">std</span>::<span class="n">mem</span>::<span class="n">transmute</span>::<span class="o">&lt;</span><span class="kt">usize</span><span class="p">,</span><span class="w"> </span><span class="o">*</span><span class="k">const</span><span class="w"> </span><span class="kt">u8</span><span class="o">&gt;</span><span class="p">(</span><span class="mi">0</span><span class="p">)</span><span class="w"> </span><span class="p">}</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>


<p>Miri knows that <code>a</code> returns a pointer, while <code>b</code> returns an integer. cg_clif sees them both as the same.</p>



<a name="209218748"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rustc%20cranelift%20backend%20for%20const%20eval/near/209218748" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rustc.20cranelift.20backend.20for.20const.20eval.html#209218748">(Sep 06 2020 at 10:14)</a>:</h4>
<p>At most <code>cg_clif</code> could be used to jit loops with only certain operations.</p>



<a name="209219201"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rustc%20cranelift%20backend%20for%20const%20eval/near/209219201" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Benedikt Mandelkow <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rustc.20cranelift.20backend.20for.20const.20eval.html#209219201">(Sep 06 2020 at 10:30)</a>:</h4>
<p>ah so 1. was a false assumption because a is allowed, I really thought this would not be allowed :D So the output of a program can change when I upgrade rustc and miri internally uses other addresses? But in that case cranelift could just return the addresses it uses as well and it would be just as different as different miri versions. <br>
I don't yet understand why the cranelift backend would not be able to compute the correct result because it needs to do the same for non const fn fns as well (generate the code which produces the correct result at runtime and this code would just be executed at compile time in this case)?</p>



<a name="209219555"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rustc%20cranelift%20backend%20for%20const%20eval/near/209219555" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rustc.20cranelift.20backend.20for.20const.20eval.html#209219555">(Sep 06 2020 at 10:42)</a>:</h4>
<blockquote>
<p>But in that case cranelift could just return the addresses it uses as well and it would be just as different as different miri versions. </p>
</blockquote>
<p>The problem is that the address is not known at compile time. It is the responsibility of the (dynamic) linker to pick an address for every symbol (function, static or promoted value). When running code at compile time, you have to make sure that you know which parts of a memory allocation are relocations to other memory allocations/functions, so you can emit the appropriate relocations for the linker to load. When running code at runtime it is fine to just treat pointers as plain integers.</p>



<a name="209219621"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rustc%20cranelift%20backend%20for%20const%20eval/near/209219621" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Benedikt Mandelkow <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rustc.20cranelift.20backend.20for.20const.20eval.html#209219621">(Sep 06 2020 at 10:44)</a>:</h4>
<p>aaah so you have this dependency on the linker where I assumed you would just put the 0 somewhere during compilation and &amp;0 would basically be const eval implementation defined and at the time it arrives at the linker it would be a constant.</p>
<p>this makes sense I will think about that :)</p>



<a name="209219671"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rustc%20cranelift%20backend%20for%20const%20eval/near/209219671" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rustc.20cranelift.20backend.20for.20const.20eval.html#209219671">(Sep 06 2020 at 10:46)</a>:</h4>
<p>Yes, that is correct.</p>



<a name="209219690"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rustc%20cranelift%20backend%20for%20const%20eval/near/209219690" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Benedikt Mandelkow <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rustc.20cranelift.20backend.20for.20const.20eval.html#209219690">(Sep 06 2020 at 10:47)</a>:</h4>
<p>I assume though that you could add this sort of virtual address to cranelift as well but at that point the cranelfit backend will be slower and basically turn into miri with a little bit of jit so its less clear if thats still worth it</p>



<a name="209219740"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rustc%20cranelift%20backend%20for%20const%20eval/near/209219740" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Benedikt Mandelkow <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rustc.20cranelift.20backend.20for.20const.20eval.html#209219740">(Sep 06 2020 at 10:49)</a>:</h4>
<p>cause there are probably other similar issues</p>



<a name="209219803"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rustc%20cranelift%20backend%20for%20const%20eval/near/209219803" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rustc.20cranelift.20backend.20for.20const.20eval.html#209219803">(Sep 06 2020 at 10:50)</a>:</h4>
<p>Yes, it would technically be possible to do this. It would probably be more complex than the miri implementation though and it would make both compile time and runtime slower.</p>



<a name="209220067"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rustc%20cranelift%20backend%20for%20const%20eval/near/209220067" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Benedikt Mandelkow <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rustc.20cranelift.20backend.20for.20const.20eval.html#209220067">(Sep 06 2020 at 10:56)</a>:</h4>
<p>yes ok... thanks for your work btw :D</p>



<a name="209220076"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rustc%20cranelift%20backend%20for%20const%20eval/near/209220076" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bjorn3 <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rustc.20cranelift.20backend.20for.20const.20eval.html#209220076">(Sep 06 2020 at 10:56)</a>:</h4>
<p>Thanks!</p>



<a name="209220288"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/rustc%20cranelift%20backend%20for%20const%20eval/near/209220288" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Benedikt Mandelkow <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/rustc.20cranelift.20backend.20for.20const.20eval.html#209220288">(Sep 06 2020 at 11:02)</a>:</h4>
<p><span class="user-mention silent" data-user-id="309872">Benedikt Mandelkow</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/rustc.20cranelift.20backend.20for.20const.20eval/near/209219621">said</a>:</p>
<blockquote>
<p>aaah so you have this dependency on the linker where I assumed you would just put the 0 somewhere during compilation and &amp;0 would basically be const eval implementation defined and at the time it arrives at the linker it would be a constant.</p>
<p>this makes sense I will think about that :)</p>
</blockquote>
<p>(actually oli-obk pretty much said the exact same thing to me (the problem with the linker) but I did not understand it because of this)</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>